運用設計の検討項目
ここからは，運用設計について説明します。一般に運用設計とは，運用業務プロセスや手順書などの作成を指します。しかし実際はそれらだけでなく，運用業務を自動化するために（アプリケーションに）監視用のAPIを実装したり，運用証跡を残すためにロギング機能を追加したりと，システム設計に影響することもたくさんあります。だからこそ運用設計は，Webアーキテクチャの設計段階で実施することが重要です。
忘れてはならない異常系の設計
運用設計では，正常系と異常系の2種類のオペレーションを検討します。正常系とは通常オペレーションのことであり，異常系とはインシデント管理→問題管理→変更管理という一連のフェーズでのオペレーションのことです（図1）。
 |
| 図1●運用設計の項目と代表的な成果物 運用設計では，正常系のオペレーションと異常系のオペレーションの二つを考える必要がある。異常系のオペレーション設計としては，インシデントの検知や対処，問題管理や変更管理のプロセスを掘り下げ，業務マニュアルに手順を明記する [画像のクリックで拡大表示] |
正常系の運用設計では，システムでサービスを提供し続けるための条件を考えます。例えば，ほかのどのシステムと連携できる必要があるか，どのシステム・リソースを継続動作させねばならないか，どのデータのバックアップが必要か――などを検討します。これらの前提条件が満たされていることのチェック方法を同時に考えます。このときの視点は，「正常であることを確認する」というものです。
忘れずに設計したいのが，異常系です。異常が起こってから手順を考えるような場当たり的な対処では，障害時に復旧に手間取ったり，原因究明に必要な情報を失ったりと傷口を広げかねません。設計段階で発生し得るインシデントを予想し，実施すべきオペレーションや実装すべき機能を設計します。
最初に検討するのは，インシデントの検知方法です。システムに求められている可用性の要件などに基づいて考えます。高可用性を求められていれば，検知は早く，予防的な視点であるべきです。具体的には，システムのリソース使用量を常時監視し，しきい値を超えたら異常が起こる前に警告を通知するといった仕組みが必要になります。監視項目は，ハードウエアの死活とリソース使用量，OSの死活とそのログ，ミドルウエアやアプリケーションのプロセス状況とそのログ，パフォーマンス――などを組み合わせるべきです。
ただし，仕組みで検知できるのは，インシデントの発生条件をシステムの設計者や管理者が明確に定義できる場合に限られます。現実には事前定義できないインシデントも発生しますので，サービスデスク（ヘルプデスクやサポートの一元的な窓口）を設置し，利用者の問い合わせによってインシデントを検知できる人的体制を整備しなければなりません。
さほど高い可用性を求められていない場合は，サービスデスクを設置するだけにとどめ，利用者からの問い合わせをきっかけにインシデントに対処する方法もあります。ですがこの方法では，利用者に迷惑をかける可能性が高く，できれば自動検知の仕組みを構築し，利用者に迷惑をかける可能性を少しでも下げたいところです。自動検知の仕組み作りには初期費用が必要ですが，運用期間でならすと微々たる出費ということもあります。オープンソースの統合管理ソフト（例えばHinemos）を検討するのもよいでしょう。
種類ごとに担当者を決めておく
検知方法の次は，インシデントの対処策を設計します。対処策では，「何を」するかだけでなく，インシデントの種類ごとに「誰が」実施するかを決めておきます。そのためインシデントが発生したら，その種類を見極め，誰が原因究明と対処に当たるかを大まかに絞り込むこと（「一次切り分け」と呼びます）が必要になります。種類の見分け方や対処方法は，マニュアルに具体的に明記します。対処担当者だけでは手に負えず，ベンダーなどの協力が必要な場合は，連絡先，必要な情報の収集法なども，手順化して記載します。保守契約の締結なども，設計時点で掘り下げておくことが肝心です。
解決策を適用する場合，いきなり本番環境に適用するのは危険です。事前にテスト環境やステージング環境（保守環境）で検証し，本番環境にリリースするというプロセスを踏むべきです。このとき単に環境を作るだけではなく，テスト環境からステージング環境に移行するときに責任者の承認を得るなど，体制を含めて整備しなければなりません。こうした本番化への手順管理を「リリース管理」と呼びます（図2）。
 |
| 図2●リリース管理業務の設計例 テスト環境で動作検証したアプリケーションは，本番環境にリリースする前にステージング環境（保守環境）で受け入れテストを実施する。問題ない場合にのみ，本番環境に移行する。それぞれの環境から移行するときには，責任者のチェックと承認を経ることで，個人の作業ミスを防ぐ。こうしたプロセスを設計する一方で，リリース管理システムの整備などが必要になる [画像のクリックで拡大表示] |
可用性の観点からシステムを停止できない場合は，縮退運転による順次リリースや，複数台あるサーバー機に時間差でパッチを適用していく「ローリング・アップデート」などの手法も考慮に入れ，リリースの手順と仕組みを整備しなければなりません。スケジュールに沿って自動リリースする運用支援ツールなどが未整備であれば，システム設計に反映しなければならないこともあります。
|
